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REMARKS - General 

1. Claims 18-31 are pending in the present application. 

2. Claim 30 is rejected under 35 USC 102 re Paleiov, et al Applicant respectfully 
requests reconsideration in light of the fact that Paleiov, et al does not clearly specify 
"said embedded computer has the means to convert voice signals to computer 
readable and storable data". Paleiov, et al does teach that the DTMF protocol system 
includes the means to input user data in the form of a voice data field (Col . 6 , 
lines 66-67 and Col. 7, lines 1-3; Col. 8, Table II). 

Although Paleiov, et al do briefly mention "speech synthesis and speech recognition 
capabilities" (Col . 6, lines 66-67; Col. 8, lines 55-56), it is unclear 
from the description exactly how this technology would be used, except for "the 
voice output and input fields may have text payloads, which 
are respectively converted to or from audio signals by the 
subscriber unit" (Col . 8, lines 56-58). Applicant's claim 30 specifies 
that the IVR menus that are to be displayed for the user, are converted directly and 
entirely from the voice IVR analog signals received from the IVR computer system, 
i.e. the voice IVR received data is automatically, and entirely translated into text data 
by the user's telephone, and thereby displayed to the user for interaction. 

3. A discussion of the Paleiov, et al reference is believed to be helpful in evaluating the 
limitations Applicant has included in the claims 18-31: 

a. Paleiov et al teaches a bi-directional protocol (Col . 2 , lines 56-57 ; 
Col. 5, lines 24-28; Col. 6, lines 6-8; Col. 7, lines 38- 
41) that uses a protocol encoded in DTMF signaling, in both directions, to 
retrieve data fundamentals pre-stored in the user's phone system, and to 
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format and to display text and graphical information for an associated IVR 
phone call. 

b. The IVR visual display layout of the data is predetermined (Col . 6 , 
lines 4-17) using an authoring computer system (Fig . 1 , element 
29; Col. 7, lines 56-67), whereby the screen layout is determined and 
converted to the DTMF protocol's data elements, which are then stored in the 
IVR computer (Fig. 1, element 28; Fig. 3, step 52; Col. 7, 
lines 64-67). The IVR computer then transmits the encoded screen layout 
to the user upon initiation ofa call by the user (Col. 5, lines 18-31; 
Col. 7, lines 15-22). Note that at no time does the user directly interact 
with the IVR authoring system (Fig . 1 , element 2 9). The user interacts 
directly, and only with the IVR host (Fig. 1; Fig. 3; Col. 9, lines 
2-7; Col. 9, lines 14-17). 

c. Furthermore, Applicant was unable to locate an embodiment in Paleiov, et, 
al 9 that includes the means for the user to browse IVR display data, without 
first connecting to the IVR system. Paleiov, et al teaches that the DTMF 
protocol specifies the display layout and encoded data that the user's decoding 
box decodes (Fig. 1, element 36; Fig. 2, block 42; Fig. 3, 
block 56) and converts to displayable information, which the user interacts 
with. Because the CCITT DTMF specification is limited to sixteen (16) 
elements (i.e. the characters: 1, 2 , 3, 4, 5, 6, 7 , 8, 9 , 0 , A, B, 

C , D * , #), without a look-up table it would be impossible to display all 
characters, for example, that exist on a standard QWERTY keyboard. 
Paleiov, et, ah teaches that the DTMF protocol, received from the IVR host 
(Fig. 1, element 28) is decoded by the user's decoding box (Fig . 1, 
element 36; Fig. 3, block 5 6) and is directly used to retrieve 
predefined display elements stored in the user unit's "factory-programmed 
memory 4 6" (Col . 7 , lines 30-38). In extrapolation, if the user were to 
dump the Paleiov, et al. "factory-programmed memory 4 6", the user 
would not be able interpret any display screens without first receiving direct- 
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connect DTMF screen protocol data from the IVR system, for a particular 
phone number. In contrast, Applicant's claimed invention teaches the pre- 
storing of all text menus associated with a specific phone number's IVR menu 
system. Hence, by extrapolation, if a user were to dump the Applicant's 
claimed phone's embedded computer memory, then the user would be able to 
discern the textual IVR menus for a specific phone number. Furthermore, the 
Applicant's claimed invention does not require the IVR system to send DTMF 
tones in order for the user to receive, display and navigate any associated text 
menus. 

d. Paleiov, et al teaches that all of the text and other graphical elements that 
could be used to display information to the user, i.e. data received in the 
specified encoded DTMF protocol, is pre-stored in the user's device's 
memory (Fig. 2 element 4 6; Col. 2, lines 50-53), i.e. the 
"factory-programmed memory 46"(Col. 7, line 34). As far as the 
applicant understands from the Paleiov, el al specification, the equivalent of a 
look-up table (Co 1. 2, lines 50-53) is stored in said factory- 
programmed memory, from which displayed elements are retrieved based on 
codes received from the IVR host using the specified DTMF protocol (Col . 

2 , lines 58-62). Applicant is unable to find any embodiment in Paleiov, 
et al, that includes the capability to update said "factory-programmed 
memory 4 6". In contrast, Applicant's claimed invention includes said update 
capability of user's, locally pre-stored visual menu text data (Applicant claims 
19, 22, 25 and 28). 

e. A general note that Applicant was unable to find any reference of the term 
"modem" in the Paleiov, el al patent. Applicant did not find any discussion 
about using "a modem attached to said user embedded computer for receiving 
said text data to display visual menus and other data on said user embedded 
computer display screen from a source computer" (Office Action, discussion 
point [8]), from which the user's phone system can download updates, etc. 
that are used in an IVR call. By inference, it is understood that the user's 
phone system in Paleiov, el al uses a DTMF "modem" in order to encode and 
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decode data in the specified DTMF protocol (Fig . 1). The problem with 
simply using a DTMF modem chip, such as Philips Semiconductors 
PCD331 1C and PCD3312C "DTMF/modem/musical-tone generators", is that 
it requires a protocol to be specified between both ends of the IVR 
communications in order for more than the standard CCITT DTMF characters 
(see discussion item [c] above) to be communicated. Paleiov, el al in fact 
teaches using a bi-directional DTMF protocol (see discussion item [a] above). 
In contrast, Applicant's claimed invention uses standard, off-the-shelf, analog 
modems (e.g. V.90 and V.92) and broadband modems (e.g. for ADSL, cable, 
etc.) to transmit any and all binary data, including ASCII text, without the 
need of an additional protocol, etc. from said source computer to said user 
telephone. 

4. Applicant submits that these differences discussed above are reflected in the claims 
and respectfully requests any suggestions by the examiner in further clarifying these 
distinctions so that the claims may be allowed. 

5. Claims 19-23, 25-29 and 31 depend from presumably allowable independent claims 
and should be allowed for at least that reason. 

6. Rejection of claims 18-31 under 35 USC 103(a) as being unpatentable over Paleiov, 
el al in view of Rosen, et al, is overcome because Paleiov, el al and Rosen, et al do 
not contain any justification to support their combination, much less in the manner 
proposed. With regard to the proposed combination of Paleiov, el al and Rosen, et al 
it is well known that in order for any prior art references themselves to be validly 
combined for use in a prior art USC 103 rejection, the references themselves (or some 
other prior art) must suggest that they be combined. For example, it was stated in In 
re Sernaker , 217 U.S.P.O 1,6 (C.A.F.C. 1983): 

"[P]rior art references in combination do not make an invention obvious 
unless something in the prior art references would suggest the advantage 
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be derived from combination of their teaching." 

That the suggestion to combine the references should not come from applicant was 
forcefully stated in Orthopedic Equipment Co. v. United States , 217 U.S.P.O. 193, 
199 (C.A.F.C 1983): 

"It is wrong to use the patent in suit [here the patent application] as a 
guide through a maze of prior art references, combining the right 
references in the right way to achieve the result of the claims in suit [here 
the claims pending]. Monday morning quarterbacking is quite improper 
when resolving the question of nonobviousness in a court of law [here the 
PTO]." 

As was further stated in Uniroyah Inc. v. Rudkin- Wiley Corp. , 5 U.S.P.O. 2d 
1434 (C.A.F.C. 1988): 

"[w]here prior-art references require selective combination by the court to 
render obvious a subsequent patent , there must be some reason for the 
combination other than the hindsight gleaned from the invention itself. .... 
Something in the prior art must suggest the desirability and thus the 
obviousness of making the combination." 

Furthermore, in the last O.A. the reason given to support the proposed 
combination is: 

"Rosen et al teach that the pre-stored text data 
comprises location data of said source computer on 
said computer communications network". 
Rosen et al does not teach that the location data of the source computer, i.e. the 
resource server (Fig . 1 , element 12 0 in Rosen et al) is stored locally in the 
"user interface device 133". 
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Rosen et al teaches that a geographic location device (Fig . 1 , e lement 132) 
communicates the user interface device's location to a resolution server (Fig . 
1, element 110; Fig. 2; Col. 4, lines 44-61 and Col. 5, 
lines 6-27) via a communications network (Fig . 1 , element 100). The 
resolution server stores the "location data of said source computer", i.e. the 
resolution server 1 10 in Rosen et al. In contrast, Applicant's claimed invention 
teaches the pre-storing of location data for said source computer, in said 
embedded computer memory of the user's telephone. Hence obviating the need to 
connect to the IVR system via a communications network, to retrieve the location 
data of the said source computer. 

Applicant therefore submits that combining is not legally justified and is therefore 
improper. Thus Applicant submits that the rejection on these references is also 
improper and should be withdrawn. 

Conclusion 

For all of the above reasons, Applicant submits that the claims all define patentability 
over the prior art. Therefore, Applicant submits that this application is now in condition 
for allowance, of which action is respectfully solicited. 
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Request For Constructive Assistance 



The undersigned has made a diligent effort to amend the claims of this application so that 
they define a novel method, which is also submitted to render the claimed method 
unobvious because it produces new and unexpected results. If, for any reason the claims 
of this application are not believed to be in full condition for allowance, applicant 
respectfully requests the constructive assistance and suggestions of the Examiner in 
drafting one or more claims pursuant to MPEP 707.07(j)> or in making constructive 
suggestions pursuant to MPEP 706.03(d) in order that this application can be placed in 
allowance as soon as possible and without the need for further proceedings. 



Very Respectfully, 



Letter Sussman 
Applicant Pro Se 
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Certificate of Mailing 



I certify that this correspondence will be deposited with the United States Postal Service 
as first class mail with proper postage affixed in an envelope addressed to: 
"Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450" on the date 
below. 



Date: 2005, March 2 




Lester Sussman, Applicant 



